Conversation
|
Apparently Payara 7.x has a minor bug - any API call with a colon in it fails. payara/Payara#7777 - looks like we need to wait for 7.2025.3 or 7.2026.1 + |
There's been an unofficial report that this is fixed in 7.2026.1 - can now move forward and try that. |
cmbz
added
FY26 Sprint 15
@qqmyers Hit this when building the warfile, could you please refresh your branch when you get a chance? Thanks! |
|
Tests passed: |
|
Passed with payara7 2026.2: |
|
Pass after develop merge: |
|
|
||
| `sudo -u dataverse vi /usr/local/payara6/glassfish/domains/domain1/config/jhove.conf` | ||
|
|
||
| 1. Copy logos from Payara 6 to Payara 7. |
There was a problem hiding this comment.
In addition to logos, we now have docroot/featuredItems/ as well. (I don't think this is an HDV-specific thing, is it?)
Sitemap usually lives in docroot, on most instances. Should probably transfer that as well, to be used until the new one is generated.
Should we just tell them to move the entire docroot?
sudo -u dataverse mv /usr/local/payara7/glassfish/domains/domain1/docroot /usr/local/payara7/glassfish/domains/domain1/docroot.orig
sudo -u dataverse mv /usr/local/payara6/glassfish/domains/domain1/docroot /usr/local/payara7/glassfish/domains/domain1/docroot
There was a problem hiding this comment.
(unless are aware of anything uniquely useful in the docroot shipped with Payara 7)
There was a problem hiding this comment.
Featured items are only visible from the SPA, which I think only we are running, so I think I'd prefer to leave it out.
For the sitemap, the cron job they set up at https://guides.dataverse.org/en/6.9/installation/config.html#creating-a-sitemap-and-submitting-it-to-search-engines should continue to work but I'll add a note. Update: added in 05c503e.
Of course, if you think we should transfer the entire docroot, we can. No strong option.
There was a problem hiding this comment.
I was wondering if it was SPA-specific (didn't see any references to it in our code), but wasn't sure.
As for the sitemap, I did say to be used until the new one is generated - i.e., yes, the next time the crontab run it'll fix itself.
Saw the commit where you mentioned the crontab - 👍; it may be worth adding a generic warning that they need to make sure any scripts outside of Dataverse proper, such as crontabs, that have the domain directory hard-coded may need to be updated (or they can create a symlink from payara6 domain to the new one, to be safe).
Unless you already have it spelled out - ?
|
|
||
| 1. Copy `jhove.conf` and `jhoveConfig.xsd` from Payara 6, edit and change `payara6` to `payara7`. | ||
|
|
||
| `sudo bash -c 'cp /usr/local/payara6/glassfish/domains/domain1/config/jhove* /usr/local/payara7/glassfish/domains/domain1/config'` |
There was a problem hiding this comment.
We should probably stick to suggesting sudo -u dataverse consistently.
Also, (just curious) why not just
sudo -u dataverse cp /usr/local/payara6/glassfish/domains/domain1/config/jhove* /usr/local/payara7/glassfish/domains/domain1/config?
... is something crazy going to happen if the current user can't read domain1/config, and the sudo account uses tcsh?
There was a problem hiding this comment.
Yeah, the craziness is due to the wildcard, the jhove*. This is what I got to work.
There was a problem hiding this comment.
FWIW, I would just go with 2 simple cp lines, 1 for each file. But, whatever works/don't fix what ain't broke, etc.
But Iet's add -u dataverse to that sudo.
| </servlet-mapping> | ||
| ``` | ||
|
|
||
| 1. Check the `Xmx` setting in `domain.xml`. |
There was a problem hiding this comment.
Small thing, but maybe all the domain.xml-related sections should be in one place. (i.e., move this up/swap it with the default-web.xml section above; plus the other sections below that deal with the config in domain.xml)
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
Co-authored-by: landreev <leonid@hmdc.harvard.edu>
|
|
||
| 1. Stop Payara 6, if running. | ||
|
|
||
| Payara 6 should already be stopped because of the Java upgrade above. |
There was a problem hiding this comment.
If payara should be stopped, it needs to be started to undeploy v6.9. Maybe the undeploy step could happen ealier, or sudo -u dataverse /usr/local/payara6/bin/asadmin start-domain could be added in the previous step?
There was a problem hiding this comment.
@wshahn this is good feedback. This step and the one above it could be deleted, honestly. During the Java 21 upgrade they should have already undeployed the war file and stopped Payara. That's why I wrote "if deployed" and "if running".
7 participants
What this PR does / why we need it: This PR updates Dataverse to be compatible with Payara
7.2025.27.2026.2 and Java 21. Aside from the doc changes (payara6 -> payara7 etc.) the changes were relatively minor - a couple deprecated annotations we use (NotEmpty, NotBlank) were removed and replaced with new ones, and some of the EE related classes we mock in tests now have a few more methods that have to be overridden.Which issue(s) this PR closes:
Special notes for your reviewer: Someone will need to check the Docker related compose files and documentation to make the relevant updates to Payara and Java. I tried to avoid updating things related to the Keycloak container since it shouldn't need to update to Java 21.
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here: No
Is there a release notes update needed for this change?: included.
Additional documentation: A good starting point: https://dataverse-guide--12043.org.readthedocs.build/en/12043/installation/prerequisites.html#payara